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Advice to the Trustees of the IETF Trust 
on Rights to Be Granted in IETF Documents 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 


Copyright (c) 2008 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 


Abstract 


Contributors grant intellectual property rights to the IETF. The 
IETF Trust holds and manages those rights on behalf of the IETF. The 
Trustees of the IETF Trust are responsible for that management. This 
management includes granting the licenses to copy, implement, and 
otherwise use IETF Contributions, among them Internet-Drafts and 
RFCs. The Trustees of the IETF Trust accepts direction from the IETF 
regarding the rights to be granted. This document describes the 
desires of the IETF regarding outbound rights to be granted in IETF 
Contributions. 
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1. Introduction 


Under the current operational and administrative structures, IETF 
intellectual property rights are vested in the IETF Trust 
administered by a board of trustees made up of the members of the 
IAOC [RFC4371]. This includes the right to make use of IETF 
Contributions, as granted by Contributors under the rules laid ou 
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[RFC5378]. The Trustees of the IETF Trust are therefore responsible 


for defining the rights to copy granted by the IETF to people who 
wish to make use of the material in these documents. 


For consistency and clarity, this document uses the same terminol 
laid out in [RFC5378] and uses the same meanings as defined in th 
document. 


The IETF Trust, by way of its Trustees, has indicated, as is 
consistent with the IETF structure, that it will respect the wish 


ogy 
at 


of the IETF in regard to what these granted rights ought to be. 


es 
It 


is therefore the IETF’s responsibility to articulate those wishes. 
This document represents the wishes of the IETF regarding the rights 


granted to all users in regard to IETF Contributions, until it is 
superseded. 


2. Purpose in Granting Rights 
In providing a description of the wishes of the IETF with regard 


rights granted in RFCs, it is helpful to keep in mind the purpose 
granting such rights. 


to 
of 
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The mission of the IETF is to produce documents that make the 
Internet work better (see [RFC3935] for more details). These 
documents, when completed, are published as RFCs. 


An important subclass of RFCs is standards describing protocols; for 
these, the primary value to the Internet is the ability of 
implementors to build solutions (products, software, etc.) that 
interoperate using these standards. Hence, the IETF has a strong 
interest in seeing accurate, interoperable implementations of the 
material the IETF publishes. The IETF Trust grants rights to copy to 
people to make use of the text in the RFCs in order to encourage 
accurate and interoperable implementations. 


As early implementations from Internet-Drafts make use of 
descriptions in those Internet-Drafts, similar desires apply to 
Internet-Drafts. 


Similar considerations also apply to non-standard, non-protocol 
documents such as BCP (Best Current Practice) and Informational 
documents; in this document, we recommend a common approach to the 
issue of right-to-use licenses for all IETF documents. 


Previous documents regarding rights in IETF documents have included 
in the RFC text specific text to be used to achieve the stated goals. 
This has proved problematic. When problems are found with such text, 
even when the problem is not a change in intent, it is necessary to 
revise the RFC to fix the problem. At best, this delays fixing legal 
issues that need prompt attention. As such, this document describes 
the IETF desires to the Trustees of the IETF Trust, but does not 
provide the specific legal wording to address the goals. The 
selection, and updating as necessary, of legal wording is left to the 
Trustees of the IETF Trust. Appeals of the actions of the Trustees 
of the IETF Trust are governed by other documents. As the Trustees 
are the members of the IAOC, the appeals procedure documented in BCP 
101 (currently [RFC4371]) is applicable. 


3. Powers and Authority 


As described in the introduction, and formally specified in 
[RFC5378], the legal authority for determining and granting users 
rights to copy material in RFCs and other IETF Contributions rests 
with the Trustees for the IETF Trust, which is made up of the members 
of the IAOC, as described in [RFC4071] and [RFC4371]. This document 
provides guidance to that body, based on the rough consensus of the 
IETF. The Trustees of the IETF Trust have the authority and 
responsibility to determine the exact text insertions (or other 
mechanisms), if any, needed in Internet-Drafts, RFCs, and all IETF 
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Contributions to meet these goals. The IETF Trust License Policy is 
available from http://trustee.ietf.org/license-info. 


The rough consensus described in this document reflects the agreement 
of the IETF as of the IETF Last Call, and the Trustees of the IETF 
Trust are to begin drafting license text and other materials to act 
on these instructions upon IESG approval of this document for RFC 
publication. Changes to the IETF documentation, and document 
policies themselves, take effect as determined by the Trustees of the 
IETF Trust. 


This document does not specify what rights the IETF Trust receives 
from others in IETF Contributions. That is left to another document 
([RFC5378]). While care has been taken by the working group in 
developing this document, and care will be taken by the Trustees of 
the IETF Trust, to see that sufficient rights are granted to the IETF 
Trust in IETF Contributions, it is also the case that the Trust can 
not grant rights it has not or does not receive, and it is expected 
that policies will be in line with that fact. Similarly, the rights 
granted for pre-existing documents can not be expanded unless the 
holders of rights in those Contributions choose to grant expanded 
rights. Nonetheless, to the degree it can, and without embarking on 
a massive effort, it is desirable if similar rights to those 
described below can be granted in older RFCs. 


4. Recommended Grants of Right to Copy 


The IETF grants rights to copy and modify parts of IETF Contributions 
in order to meet the objectives described earlier. As such, 
different circumstances and different parts of documents may need 
different grants. This section contains subsections for each such 
different grant that is currently envisioned. Each section is 
intended to describe a particular usage, to describe how that usage 
is recognizable, and to provide guidance to the Trustees of the IETF 
Trust as to what rights the IETF would like to see granted in that 
circumstance and what limitations should be put on such granting. 


These recommendations for outgoing rights are structured around the 
assumptions documented in [RFC5378]. Thus, this document is about 
granting rights derived from those granted to the IETF Trust. The 
recommendations below are how those granted rights should in turn be 
passed on to others using IETF documents in ways and for purposes 
that fit with the goals of the IETF. This discussion is also 
separate from discussion of the rights the IETF itself requires in 
documents to do its job, as those are not "outbound" rights. It is 
expected that the rights granted to the IETF will be a superset of 
those copying rights we wish to grant to others. 
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4.1. Rights Granted for Reproduction of RFCs 


It has long been IETF policy to encourage copying of RFCs in full. 
This permits wide dissemination of the material, without risking loss 
of context or meaning. The IETF wishes to continue to permit anyone 
to make full copies and translations of RFCs. 


4.2. Rights Granted for Quoting from IETF Contributions 


There is rough consensus that it is useful to permit quoting without 
modification of excerpts from IETF Contributions. Such excerpts may 
be of any length and in any context. Translation of quotations is 
also to be permitted. All such quotations should be attributed 
properly to the IETF and the IETF Contribution from which they are 
taken. 


4.3. Rights Granted for Implementing Based on IETF Contributions 


IETF Contributions often include components intended to be directly 
processed by a computer. Examples of these include ABNF definitions, 
XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, 
MIBs, ASN.1, and classical programming code. These are included in 
IETF Contributions for clarity and precision in specification. It is 
clearly beneficial, when such items are included in IETF 
Contributions, to permit the inclusion of such code components in 
products that implement the Contribution. It has been pointed out 
that in several important contexts, use of such code requires the 
ability to modify the code. One common example of this is simply the 
need to adapt code for use in specific contexts (languages, 
compilers, tool systems, etc.) Such use frequently requires some 
changes to the text of the code from the IETF Contribution. Another 
example is that code included in open source products is frequently 
licensed to permit any and all of the code to be modified. Since we 
want this code included in such products, it follows that we need to 
permit such modification. While there has been discussion of 
restricting in some way the rights to make such modifications, the 
rough consensus of the IETF is that such restrictions are likely a 
bad idea, and are certainly very complex to define. 


As such, the rough consensus is that the IETF Trust is to grant 
rights such that code components of IETF Contributions can be 
extracted, modified, and used by anyone in any way desired. To 
enable the broadest possible extraction, modification, and usage, the 
IETF Trust should avoid adding software license obligations beyond 
those already present in a Contribution. The granted rights to 
extract, modify, and use code should allow creation of derived works 
outside the IETF that may carry additional license obligations. As 
the IETF Trust can not grant rights it does not receive, the rights 
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to extract, modify, and use code described in this paragraph can not 
be granted in IETF Contributions that are explicitly marked as not 
permitting derivative works. 


While it is up to the Trustees of the IETF Trust to determine the 
best way of meeting this objective, two mechanisms are suggested here 
that are believed to be helpful in documenting the intended grant to 
readers and users of IETF Contributions. 


Firstly, the Trustees of the IETF Trust should maintain, ina 
suitable, easily accessible fashion, a list of common RFC components 
that will be considered to be code. To start, this list should 
include at least the items listed above. The Trustees of the IETF 
Trust will add to this list as they deem suitable or as they are 
directed by the IETF. 


Additionally, the Trustees of the IETF Trust should define a textual 
representation to be included in an IETF Contribution to indicate 
that a portion of the document is considered by the authors (and 
later, the working group, and upon approval, the IETF) to be code and 
thus subject to the permissions granted to use code. 


4.4. Rights Granted for Use of Text from IETF Contributions 


There is no consensus at this time to permit the use of text from 
RFCs in contexts where the right to modify the text is required. The 
authors of IETF Contributions may be able and willing to grant such 
rights independently of the rights they have granted to the IETF by 
making the Contribution. 


4.5. Additional Licenses for IETF Contributions 


There have been contexts where the material in an IETF Contribution 
is also available under other license terms. The IETF wishes to be 
able to include content that is available under such licenses. It is 
desirable to indicate in the IETF Contribution that other licenses 
are available. It would be inappropriate and confusing if such 
additional licenses restricted the rights the IETF intends to grant 
in the content of RFCS. 


However, the IETF does not wish to have IETF Contributions contain 
additional licenses, as that introduces a number of additional 
difficulties. Specifically, additional text in the document, and any 
additional license referred to by permitted additional text, must not 
in any way restrict the rights the IETF intends to grant to others 
for using the contents of IETF Contributions. 
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Authors of Contributions retain all rights in their Contributions. 

As such, an author may directly grant any rights they wish separately 
from what the IETF grants. However, a reader wishing to determine or 
make use of such grants will need to either consult external sources 
of information, possibly including open source code and documents, or 
contact the author directly. 


5. IANA Considerations 


No values are assigned in this document, no registries are created, 
and there is no action assigned to the IANA by this document. One 
list (of kinds of code sections) is anticipated, to be created and 
maintained by the Trustees of the IETF Trust. It is up to the 
Trustees of the IETF Trust whether they create such a list and 
whether they choose to involve the IANA in maintaining that list. 


6. Security Considerations 


This document introduces no new security considerations. It isa 
process document about the IETF’s IPR rights being granted to other 
people. While there may be attacks against the integrity or 
effectiveness of the IETF processes, this document does not address 
such issues. 
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